Systems and methods of unified reconstruction in storage systems

ABSTRACT

Systems and methods for reconstructing unified data in an electronic storage network are provided which may include the identification and use of metadata stored centrally within the system. The metadata may be generated by a group of storage operation cells during storage operations within the network. The unified metadata is used to reconstruct data throughout the storage operation cells that may be missing, deleted or corrupt.

RELATED APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet, or any correction thereto,are hereby incorporated by reference into this application under 37 CFR1.57.

This application is also related to the following patents and pendingapplications, each of which is hereby incorporated herein by referencein its entirety:

application Ser. No. 09/354,058, titled “HIERARCHICAL BACKUP ANDRETRIEVAL SYSTEM,” filed Jul. 15, 1999, now U.S. Pat. No. 7,395,282,issued Jan. 25, 2011;

application Ser. No. 09/610,738, titled “MODULAR BACKUP AND RETRIEVALSYSTEM USED IN CONJUNCTION WITH A STORAGE AREA NETWORK,” filed Jul. 6,2000, now U.S. Pat. No. 7,035,880, issued Apr. 25, 2006;

U.S. Pat. No. 6,418,478, titled “PIPELINED HIGH SPEED DATA TRANSFERMECHANISM,” issued Jul. 9, 2002;

Application Ser. No. 60/460,234, titled “SYSTEM AND METHOD FORPERFORMING STORAGE OPERATIONS IN A COMPUTER NETWORK,” filed Apr. 3,2003, and related applications including Ser. Nos. 10/818,794,10/819,097, and 10/819,101, all filed Apr. 5, 2004; and

application Ser. No. 10/877,831, titled “HIERARCHICAL SYSTEM AND METHODFOR PERFORMING STORAGE OPERATIONS IN A COMPUTER NETWORK,” filed Jun. 25,2004, now U.S. Pat. No. 7,454,569, issued Nov. 18, 2008.

Application Ser. No. 60/519,526, titled “SYSTEM AND METHOD FORPERFORMING PIPELINED STORAGE OPERATIONS IN A COMPUTER NETWORK,” filedNov. 13, 2003, and related applications including Ser. Nos. 10/990,284and 10/990,357 both filed Nov. 15, 2004; and

application Ser. No. 11/120,619, titled “HIERARCHICAL SYSTEMS ANDMETHODS FOR PROVIDING STORAGE A UNIFIED VIEW OF STORAGE INFORMATION,”filed May 2, 2005, now U.S. Pat. No. 7,343,453, issued Mar. 11, 2008.

Application Ser. 60/752,203, titled “SYSTEMS AND METHODS FOR CLASSIFYINGAND TRANSFERRING INFORMATION IN A STORAGE NETWORK,” filed Dec. 19, 2005.

Application Ser. No. 60/752,202 titled “SYSTEMS AND METHODS FOR GRANULARRESOURCE MANAGEMENT IN A STORAGE NETWORK,” filed Dec. 19, 2005.

application Ser. No. 11/313,224, titled “SYSTEMS AND METHODS FORPERFORMING MULTI-PATH STORAGE OPERATIONS,” filed Dec. 19, 2005, now U.S.Pat. No. 7,620,710, issued Nov. 17, 2009.

Application Ser. No. 60/752,196 titled “SYSTEMS AND METHODS FORMIGRATING COMPONENTS IN A HIERARCHICAL STORAGE NETWORK,” filed Dec. 19,2005.

Application Ser. No. 60/752,201 titled “SYSTEMS AND METHODS FORRESYNCHRONIZING STORAGE OPERATIONS,” filed Dec. 19, 2005.

Application Ser. No. 60/752,197 titled “SYSTEMS AND METHODS FORHIERARCHICAL CLIENT GROUP MANAGEMENT”, filed Dec. 19, 2005.

BACKGROUND OF THE INVENTION Field of the Invention

The invention disclosed herein relates generally to performing storageoperations on electronic data in a computer network. More particularly,the present invention relates to managing metadata in a storageoperation system.

Storage management systems have evolved over time into complex entitieswith many components including hardware and software modules designed toperform a variety of different storage operations on electronic data.Current storage management systems employ a number of different methodsto perform storage operations on electronic data. For example, data canbe stored in primary storage as a primary copy or in secondary storageas various types of secondary copies including, as a backup copy, asnapshot copy, a hierarchical storage management copy (“HSM”), as anarchive copy, and as other types of copies.

A primary copy of data is generally a production copy or other “live”version of the data which is used by a software application and istypically in the native format of that application. Primary copy datamay be maintained in a local memory or other high-speed storage devicethat allows for relatively fast data access. Such primary copy data istypically retained for a period of time (e.g., a number of seconds,minutes, hours or days) before some or all of the data is stored as oneor more secondary copies, for example, to prevent loss of data in theevent a problem occurs with the data stored in primary storage.

Secondary copies may include point-in-time data and may be intended forlong-term retention (e.g., weeks, months or years depending on retentioncriteria, for example as specified in a storage policy as furtherdescribed herein) before some or all of the data is moved to otherstorage or discarded. Secondary copies may be indexed so users canbrowse and restore the data at another point in time. After certainprimary copy data is copied to secondary storage, a pointer or otherlocation indicia such as a stub may be placed in the primary copy toindicate the current location of that data.

One type of secondary copy is a backup copy. A backup copy is generallya point-in-time copy of the primary copy data stored in a backup formatas opposed to in native application format. For example, a backup copymay be stored in a backup format that is optimized for compression andefficient long-term storage. Backup copies generally have relativelylong retention periods and may be stored on media with slower retrievaltimes than other types of secondary copies and media. In some cases,backup copies may be stored at an offsite location.

Another form of secondary copy is a snapshot copy. From an end-userviewpoint, a snapshot may be thought of as a representation or image ofthe primary copy data at a given point in time. A snapshot generallycreates a bit map or block level representation of a primary copy volumeat a particular moment in time. Users typically gain a read-only accessto the record of files and directories of the snapshot. By electing torestore primary copy data from a snapshot taken at a given point intime, users may also return the current file system to the prior stateof the file system that existed when the snapshot was taken.

A snapshot may be created instantly, using a minimum of file space, butmay still function as a conventional file system backup. A snapshot maynot actually create another physical copy of all the data, but maysimply create pointers that are mapped to specific blocks of data takenat the point in time of the snapshot.

Another type of data generated by client computer systems and theirassociated networks is metadata. Metadata includes information, or data,about the data stored on the system. Metadata, while not including thesubstantive operational data of client applications is useful in theadministration, security, maintenance, and accessibility of operationaldata. Examples of metadata include files size, edit times, edit dates,locations on storage devices, version numbers, encryption codes,restrictions on access or uses, and tags of information that may includean identifier for users or clients, etc.

Whether data is stored in primary or secondary storage, it may havemetadata or other associated data useful for application or networkmanagement. Such metadata may be created by applications operating ondifferent platforms and may be stored or backed up to storage devicesthat serve different and distinct storage domains. Thus, if it isdesired to obtain metadata or other data relating to a particularapplication across a network or several clients (e.g., to obtain acollective or aggregate “unified view” of the data), it may be necessaryto communicate with the various network devices to identify and collectthe relevant metadata for use as an aid in system maintenance andadministration.

SUMMARY OF THE INVENTION

In accordance with certain aspects of the present invention, systems andmethods for identifying and merging data in an electronic storagenetwork are provided which may include the identification, collection,creation, and use of metadata stored centrally within the system. Themetadata may be generated by a group of storage operation cells duringstorage operations within the network. Such metadata is used toreconstruct client, application, or system data throughout the storageoperation network that may be missing, deleted, corrupt or otherwiseincomplete or inaccurate.

An embodiment of the present invention includes a system forreconstructing and maintaining data stored in an electronic storagenetwork. The system may include a plurality of storage operation cellsinterconnected on the network. One of the storage operation cells mayinclude a master storage manager that maintains data related to clientapplications or system management. The master storage manager maycollect the data generated by a plurality of storage operation cells andstores the data on one or more storage devices.

In another embodiment of the present invention, a method forreconstructing and maintaining client or system data stored in anelectronic storage network is provided. The method may includeidentifying and collecting data stored in a group of storage operationcells. The collected data may be stored in a central storage location,wherein the data stored in the central storage location represents acollection of integrated data obtained from various locations across theelectronic storage network.

In yet another embodiment a method of reconstructing data stored in anelectronic storage network is presented. The method may includeidentifying metadata associated with an interruption of data transferbetween first and second storage devices to determine if data present atone of the storage devices is not present at the other fault andcollecting backup metadata from a storage device.

In another embodiment of the present invention, a computer-readablemedium having sequences of instructions which, when executed by one ormore processors cause an electronic device to assign unique identifiersto a sets of metadata generated by storage operation cells, each linkedto a local storage device. It may determined whether a backup storagedevice includes a hardware identifier, if not, one is added to uniqueidentifier. The sets of metadata, may then be stored in a centralstorage device. Upon detection of a loss of metadata on the localstorage device, a corresponding set of metadata is located on thecentral storage device using the unique identifier. The lost metadatamay be reconstructed using a corresponding set of metadata on a storagedevice. The reconstructed metadata may be copied on to the local storagedevice for subsequent use.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the invention are illustrated in the figures of theaccompanying drawings which are meant to be exemplary and not limiting,in which like references are intended to refer to like or correspondingparts, and in which:

FIG. 1A is a block diagram of a storage operation cell according to anembodiment of the invention;

FIG. 1B illustrates the exchange of metadata between client computers ofa storage operation system according to an embodiment of the invention;

FIG. 1C illustrates the exchange of metadata between client computers ofa storage operation system according to another embodiment of theinvention;

FIG. 2 is a block diagram of a hierarchically organized group of storageoperation cells in a system to perform storage operations on electronicdata and metadata in a computer network according to an embodiment ofthe invention;

FIG. 3 is a block diagram of a hierarchically organized group of storageoperation cells according to an embodiment of the invention;

FIGS. 4A and 4B present a generalized block diagrams illustrating thetransfer of metadata according to an embodiment of the invention;

FIG. 5 is a flow diagram generally illustrating some of the stepsinvolved in storing metadata to a central storage device according to anembodiment of the invention;

FIG. 6 is a flow diagram of a method of reconstructing metadata within astorage operation system according to an embodiment of the invention;

FIG. 7 is a flow diagram illustrating some of the steps involved inrecovering deleted metadata within a storage operation system accordingto an embodiment of the invention;

FIG. 8 is a flow diagram illustrating some of the steps involved inusing metadata for storage system recovery operations according to anembodiment of the invention; and

FIG. 9 is a flow diagram illustrating some of the steps involved inusing metadata for identifying backed up storage media during datarecovery according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Detailed embodiments of the present invention are disclosed herein,however, it is to be understood that the disclosed embodiments aremerely exemplary of the invention, which may be embodied in variousforms. Therefore, specific functional details disclosed herein are notto be interpreted as limiting, but merely as a basis for teaching oneskilled in the art to employ the present invention in broad spectrum ofmore specific detailed embodiments.

With reference to FIGS. 1 through 9, exemplary aspects of certainfeatures of the present invention are presented. FIG. 1A illustrates ablock diagram of a storage operation cell 50 that performs storageoperations on electronic data in a computer network in accordance withan embodiment of the present invention. Storage operation cell 50 mayalso be referred to herein as a storage domain. As shown, storageoperation cell 50 may generally include a storage manager 100, a dataagent 95, a media agent 105, a storage device 115, and, in someembodiments, may include certain other components such as a client 85, adata or information store 90, databases 110 and 111, jobs agent 120, aninterface module 125, a management agent 130, and metadata manger 133.Such system and elements thereof are exemplary of a modular storagemanagement system such as the CommVault QiNetix™ system, and also theCommVault GALAXY™ backup system, available from CommVault Systems, Inc.of Oceanport, N.J., and further described in U.S. Pat. No. 7,035,880,which is incorporated herein by reference in its entirety.

A storage operation cell 50, in one embodiment, may generally includecombinations of hardware and software components associated withperforming storage operations on electronic data including the logicalassociation of physical components within the system (e.g., foradministrative or convenience purposes). Exemplary storage operationcells according to embodiments of the invention may include, as furtherdescribed herein, CommCells as embodied in the QNet storage managementsystem and the QiNetix storage management system by CommVault Systems ofOceanport, N.J. According to some embodiments of the invention, storageoperations cell 50 may be related to backup cells and provide some orall of the functionality of backup cells as described in applicationSer. No. 09/354,058.

Storage operation cells may also perform additional types of storageoperations and other types of storage management functions that are notgenerally offered by backup cells. In accordance with certainembodiments of the present invention, additional storage operationsperformed by storage operation cells may include creating, storing,retrieving, and migrating primary data copies and secondary data copies(which may include, for example, snapshot copies, backup copies, HSMcopies, archive copies, and other types of copies of electronic data).In some embodiments, storage operation cells may also provide one ormore integrated management consoles for users or system processes tointerface with in order to perform certain storage operations onelectronic data as further described herein. Such integrated managementconsoles may be displayed at a central control facility or severalsimilar consoles distributed throughout multiple network locations toprovide global or geographically specific network data storageinformation.

In some embodiments, storage operations may be performed according to astorage policy. A storage policy, generally, may be a data structure orother information source that includes a set of preferences and otherstorage criteria for performing a storage operation. The preferences andstorage criteria may include, but are not limited to, a storagelocation, relationships between system components, network pathway toutilize, retention policies, data characteristics, compression orencryption requirements, preferred system components to utilize in astorage operation, and other criteria relating to a storage operation.

Thus, a storage policy may indicate that certain data is to be stored ina specific storage device, retained for a specified period of timebefore being aged to another tier of secondary storage, copied tosecondary storage using a specified number of streams, etc. In oneembodiment, a storage policy may be stored to a storage manager database111, to archive media as metadata for use in restore operations or otherstorage operations. The storage policy may be stored to other locationsor components of the system.

A schedule policy specifies when and how often to perform storageoperations and may also specify performing certain storage operations onsub-clients of data including how to handle those sub-clients. Asub-client may represent static or dynamic associations of portions ofdata of a volume and are generally mutually exclusive. Thus, a portionof data may be given a label and the association is stored as a staticentity in an index, database or other storage location used by thesystem. Sub-clients may also be used as an effective administrativescheme of organizing data according to data type, department within theenterprise, storage preferences, etc.

For example, an administrator may find it preferable to separate e-maildata from financial data using two different sub-clients havingdifferent storage preferences, retention criteria, etc. Storageoperation cells may contain not only physical devices, but also mayrepresent logical concepts, organizations, and hierarchies. For example,a first storage operation cell 50 may be configured to perform HSMoperations, such as data backup or other types of data migration, andmay include a variety of physical components including a storage manager100 (or management agent 130), a media agent 105, a client component 85,and other components as described herein. A second storage operationcell may contain the same or similar physical components, however, itmay be configured to perform storage resource management (“SRM”)operations, such as monitoring a primary data copy or performing otherknown SRM operations.

While the first and second storage operation cells are logicallydistinct entities configured to perform different management functions(i.e., HSM and SRM respectively), each cell may contain the same orsimilar physical devices in both storage operation cells. In analternative embodiment, different storage operation cells may containsome of the same physical devices and not others. For example, a storageoperation cell 50 configured to perform SRM tasks may include a mediaagent 105, client 85, or other network device connected to a primarystorage volume, while a storage operation cell 50 configured to performHSM tasks instead may include a media agent 105, client 85, or othernetwork device connected to a secondary storage volume and not containthe elements or components associated with the primary storage volume.These two cells, in this embodiment, may include a different storagemanager 100 that coordinates storage operations via the same mediaagents 105 and storage devices 115. This “overlapping” configuration mayallow storage resources to be accessed by more than one storage manager100 such that multiple paths exist to each storage device 115facilitating failover, load balancing and promoting robust data accessvia alternative routes.

Alternatively, in another embodiment, a single storage manager 100 maycontrol two or more cells 50 (whether or not each storage cell 50 hasits own dedicated storage manager 100). Moreover, in certainembodiments, the extent or type of overlap may be user-defined (througha control console (not shown)) or may be automatically configured tooptimize data storage and/or retrieval.

In one embodiment, a data agent 95 may be a software module or part of asoftware module that is generally responsible for archiving, migrating,and recovering data from client computer 85 stored in an informationstore 90 or other memory location. Each client computer 85 may have atleast one data agent 95 and the system can support multiple clientcomputers 85. In some embodiments, data agents 95 may be distributedbetween client 85 and storage manager 100 (and any other intermediatecomponents (not shown)) or may be deployed from a remote location or itsfunctions approximated by a remote process that performs some or all ofthe functions of data agent 95. Data agent 95 may also generate metadataassociated with the data that it is generally responsible for archiving,migrating, and recovering from client computer 85. This metadata may beappended or imbedded within the client data as it is transferred to abackup or secondary storage location under the direction of storagemanager 100.

In one embodiment, the storage manager 100 may include a software moduleor other application that may coordinate and control storage operationsperformed by storage operation cell 50. The storage manager 100 maycommunicate with the elements of the storage operation cell 50 includingclient computers 85, data agents 95, media agents 105, and storagedevices 115, to initiate and manage system backups, migrations, and datarecovery.

In one embodiment of the present invention, the storage manager 100 mayinclude a jobs agent 120 that monitors the status of some or all storageoperations previously performed, currently being performed, or scheduledto be performed by the storage operation cell 50. Jobs agent 120 may belinked with agent, or an interface module 125 (typically a softwaremodule or application). The interface module 125 may include informationprocessing and display software, such as a graphical user interface(“GUI”), an application program interface (“API”), or other interactiveinterface through which users and system processes can retrieveinformation about the status of storage operations.

Through interface module 125, users may optionally issue instructions tovarious storage operation cells 50 regarding performance of the storageoperations as described and contemplated by illustrative embodiments ofthe present invention. For example, a user may utilize the GUI to viewthe status of pending storage operations in some or all of the storageoperation cells in a given network or to monitor the status of certaincomponents in a particular storage operation cell (e.g., the amount ofstorage capacity left in a particular storage device).

One embodiment of storage manager 100 may also include a managementagent 130 that is typically implemented as a software module orapplication program. A management agent 130 provides an interface thatallows various management components in other storage operation cells 50to communicate with one another. For example, one embodiment of anetwork configuration may include multiple cells 50 adjacent to oneanother or otherwise logically related in a WAN or LAN configuration(not shown). With this arrangement, each cell 50 may be connected to theother through each respective interface module 125. This allows eachcell 50 to send and receive certain pertinent information from othercells 50 including status information, routing information, informationregarding capacity and utilization, etc. These communication paths mayalso be used to convey information and instructions regarding storageoperations.

In an illustrative embodiment, a management agent 130 in the firststorage operation cell 50 may communicate with a management agent 130 ina second storage operation cell regarding the status of storageoperations in the second storage operation cell. Another illustrativeexample may include a first management agent 130 in a first storageoperation cell 50 that may communicate with a second management agent ina second storage operation cell to control the storage manager (andother components) of the second storage operation cell via the firstmanagement agent 130 contained in the storage manager 100 of the firststorage operation cell 50.

Another illustrative example may include a management agent 130 in thefirst storage operation cell 50 that may communicate directly with andcontrol the components in the second storage management cell, bypassingstorage manager 100 in the second storage management cell. In analternative embodiment, the storage operation cells 50 can also beorganized hierarchically such that hierarchically superior cells controlor pass information to hierarchically subordinate cells or vice versa.

Storage manager 100 may also maintain, in one embodiment, an indexcache, a database, or other data structure 111. The data stored indatabase 111 may be used to indicate logical associations betweencomponents of the system, user preferences, management tasks, SRM data,HSM data or other useful metadata. As further described herein, some ofthis information may be stored in a media agent database 110 or otherlocal data store. For example, the storage manager 100 may use data fromdatabase 111 to track logical associations between media agents 105 andstorage devices 115.

Storage manager 100 also may include, in one embodiment, a metadatamanager 133 or other program logic or code for identifying, coordinatingand capturing metadata from different applications and/or softwaremodules operating within a storage management system. Such metadata istypically descriptive of data running on clients 85 and may include dataprotection information such as last backup time, backup location,associated storage and/or schedule policies and other usefulcharacteristics etc. Furthermore, in some embodiments, such metadata mayinclude information describing or characterizing the data in generalincluding application information, data size, content, format etc.Application data may be identified, located and accessed through the useof the metadata corresponding to the application data. One way this maybe accomplished is through the use of filter drivers or other programlogic or code as further described in U.S. patent application entitledApplication titled “Systems and Methods for Classifying and TransferringInformation in a Storage Network, application Ser. No. 11/564,163 filedon Nov. 28, 2006, now U.S. Pat. No. 7,631,151, issued Dec. 8, 2009.

One embodiment of the storage operating system may include a singlestorage operation cell 50. Alternatively, the storage operating systemmay include multiple storage operation cells or domains that are incommunication with one another and may be distributed across differentnetwork elements (e.g., servers, networks, storage media, etc.). Ametadata manager 133 may monitor the creation and storage of metadataassociated with various different modules within the storage operationcell 50. Metadata manager 133 may also facilitate the capture andstorage of metadata generated at different times and across differentsoftware and/or hardware components of a storage domain. In oneembodiment, metadata stored in the database 110 of a media agent 105 maybe monitored by the metadata manager 133. Metadata manager 133 maydirect job agent 120 to retrieve this metadata from a database 110. Oncereceived, metadata manager 133 may coordinate storing the metadata at astorage manager database 111 (or any other local or remote storagedevice).

Metadata manager 133 may also provide metadata for display via theinterface module 120. Such processing includes, among other things,categorizing the metadata and displaying the categorized metadataaccording to user preference. The metadata manager 133 also (alone or inconjunction with the management agent 130), may send retrieved metadatato a second storage operation cell, if implemented. Similarly,management agent 130 may coordinate receiving metadata from otherstorage operation cells 50, and storing the metadata at one or moredesignated storage devices such as, for example, database 110. Forexample, metadata manager 133 may coordinate sending metadata to storagedevice 115 via one of media agents 105.

In some embodiments, metadata generally contains data associated withstorage policies and information related to system recovery. Forexample, the metadata may include information such as, but not limitedto, the source storage device location of the data (i.e., productiondata), the target storage device to which the data was backed-up, thepath taken by the data through the storage system network between thesource and target storage devices, data format information, time of datafile creation, data file size, data file format, data encryptioninformation, and other information that may be related to the process ofarchiving, migrating, and recovering data across one more storageoperation cells.

As illustrated in FIG. 1A, a media agent 105 may be implemented as asoftware module that conveys data, as directed by the storage manager100, between a client computer 85 and one or more storage devices 115such as a tape library, a magnetic media storage device, an opticalmedia storage device, or any other suitable storage device. In oneembodiment, media agents 105 may be linked with and control a storagedevice 115 associated with a. particular media agent. A media agent 105may be considered to be associated with a particular storage device 115if that media agent 105 is capable of routing and storing data to theparticular storage device 115.

Media agent 105 may also include a metadata agent 107 that manages themetadata that may be stored and created based on application data thatmay be copied or backed up to storage device 115 (or any other storagedevice via media agent 105).

In some embodiments, some or all of the metadata may be stored at anindex cache or database 110, which is associated with a media agent 105.The metadata may also be stored at any other data structure or storagedevice (not shown) managed by the media agent 105. Metadata associatedwith the media agent 105 may provide information regarding the data thatis stored in the storage devices 115. For example, the metadata mayprovide, among other things, information regarding the content type,data file size, time of storage, and network location from which thedata was sent, routing information etc., and other types of metadata asfurther described herein.

In operation, a media agent 105 associated with a particular storagedevice 115 may instruct the storage device to use a robotic arm or otherretrieval means to load or eject a certain storage media, and tosubsequently archive, migrate, or restore data to or from that media.Media agents 105 may communicate with a storage device 115 via asuitable communications path such as a SCSI or fiber channelcommunications link. In some embodiments, storage device 115 may belinked to a data agent 105 via a Storage Area Network (“SAN”).

Each media agent 105 may maintain an index cache, a database, or otherdata structure 110 which may store index data and/or other metadatagenerated during backup, migration, and restore and other storageoperations as described herein. For example, performing storageoperations on Microsoft Exchange® data may generate index data. Suchindex data provides a media agent 105 or other external device with afast and efficient mechanism for locating the data copied, stored orotherwise backed up. In some embodiments, a storage manager database 111may store data associating a client 85 with a particular media agent 105or storage device 115, as specified in a storage policy. The media agentdatabase 110 may indicate where specifically the client 85 data isstored in storage device 115, what specific files were stored, and otherinformation associated with storage of the client 85 data.

In some embodiments, such index data may be stored along with the databacked up in a storage device 115, with an additional copy of the indexdata written to index cache 110. The data in the index cache 110 is thusreadily available for use in storage operations and other activitieswithout having to be first retrieved from storage device 115. Inperforming storage operations, metadata agent 107 may access metadatafrom a database 110 in order to perform certain operations associatedwith storage device 115. The metadata may include, for example,information regarding the robot arm or other retrieval means used toload or eject certain storage media.

According to one embodiment, metadata that may be generated (e.g., atdata agent 95 or media agent 105) and stored at the media agent 105 maybe monitored and accessed by metadata agent 107 according to varioususer definable data management criteria. For example, metadata agent 107may notify the metadata manager 133 in storage manager 100 ofadditionally created metadata based on a periodic time schedule. Basedon this schedule, the storage manager may direct the transfer of thecreated metadata, for example, to a central storage device (e.g.,centralized database) where all created metadata in the storageoperation cell may be copied, for example, to database 111. According toanother example, metadata agent 107 may also notify metadata manager 133in the storage manager 100 of additionally created metadata based on acertain volume (e.g., amount of data processed, aggregate file size,etc.) of generated metadata.

In some embodiments, certain components may reside and execute on thesame computer. For example, a client computer 85 including a data agent95, a media agent 105, or a storage manager 100 coordinates and directslocal archiving, migration, and retrieval application functions asfurther described in U.S. Pat. No. 7,035,880. This client computer 85can function independently or together with other similar clientcomputers 85. An example of this embodiment is illustrated in FIG. 1B.

In the embodiment of FIG. 1B, metadata generated by each client computer85, 87, 89 may be exchanged over communications links 60, 65, and 70.For example, metadata generated at client computer 85 may be copied to astorage device or database such as the metadata storage device 102.Additionally, metadata generated at the client computer 87 may be sentto the client computer 85, and copied to the metadata storage device102.

Similarly, metadata generated by client computer 89 may also be sent toclient computer 85, and also be backed up to metadata storage device102. In this embodiment, metadata may be sent to a central storagedevice (i.e., metadata storage device 102) that may collect the metadatafrom multiple client computers 85, 97, 89 each operating one or morestorage operation cells. This may be achieved by one or more storagemanagers (e.g., storage manager 100) associated with either of theclient computers coordinating the collection of metadata from otherclient computers and backing up the collected metadata to a centralstorage device or database such as storage device 102.

Alternatively, in another as embodiment illustrated in FIG. 1C, metadatagenerated by each client computer 85, 87, 89 or storage manager or otherhost may be exchanged over communications links 62, 67, and 72 directlyto a centralized repository or database 104 for storing or backing upmetadata. In this embodiment, metadata generated at the client computers85, 87 and 89 may be sent directly to the storage device or database 104via the communication links 62, 67 and 72 respectively.

FIG. 2 presents a generalized block diagram of a hierarchicallyorganized group of storage operation cells in a system to performstorage operations on electronic data in a computer network inaccordance with an embodiment of the present invention. Although thestorage operation cells generally depicted in FIG. 2 have differentreference numbers than the cell 50 shown in FIG. 1, one skilled in theart should recognize that these cells may be configured the same as orsimilarly to storage cell 50 depicted in FIG. 1, without deviating fromthe scope of the present invention.

As shown in the embodiment of FIG. 2, the system may include a masterstorage manager component 135 and various other storage operationscells. The system includes a first storage operation cell 140, a secondstorage operation cell 145, a third storage operation cell 150, a fourthstorage operation cell 155, a fifth storage operation cell 160, and annth storage operation cell 165. It should will be understood by oneskilled in the art this illustration is only exemplary and that fewer ormore storage operation cells may be present or differentlyinterconnected if desired.

Storage operation cells, such as the ones shown in the embodiment ofFIG. 2 may be linked and hierarchically organized. A master storagemanager 135 may be associated with, communicate with, and direct storageoperations for a first storage operation cell 140, a second storageoperation cell 145, a third storage operation cell 150, a fourth storageoperation cell 155, a fifth storage operation cell 160, and an nthstorage operation cell 165. In some embodiments, the master storagemanager 135 may not be part of any particular storage operation cell. Inother embodiments (not shown), master storage manager 135 may itself bepart of a certain storage operation cell.

In operation, the master storage manager 135 may communicate with amanagement agent of the storage manager of the first storage operationcell 140 (or directly with the other components of first cell 140) withrespect to storage operations performed in the first storage operationcell 140. For example, in some embodiments, the master storage manager135 may instruct the first storage operation cell 140 with certaincommands regarding a desired storage operation, such as how and when toperform particular storage operations including the type of operationand the data on which to perform the operation.

In alternative embodiments, the master storage manager 135 may track thestatus of its associated storage operation cells. The master storagemanager 135 may periodically poll and track the status of jobs, systemcomponents, system resources, metadata information and other items, bycommunicating with the manager agents (or other components) in therespective storage operation cells. Moreover, the master storage manager135 may track the status of its associated storage operation cells byreceiving periodic status updates from the manager agents (or othercomponents) in the respective cells regarding jobs, system components,system resources, and other items.

Master storage manager 135 may monitor an analyze network resources, forexample, to map network pathways and topologies to, among other things,physically monitor storage operations, to determine alternate routes forstoring data as further described herein. Other methods of monitoringthe storage operations cells may include periodic polling by a monitoragent, pre-configured threshold responses, etc. Pre-configured thresholdresponses may be triggered if a storage operation cell exceeds athreshold value defined by a system administrator (e.g., file size,storage availability, traffic congestion, data transfer rate, etc.).

While the embodiments described herein describe a variety of networkcharacteristics which a storage manager may monitor and control, oneskilled in the art will recognize that such characteristics areillustrative and any suitable operational characteristic associated witha electronic storage network may be monitored and used a basis forestablishing an operation threshold without deviating from the scope ofthe present invention.

Master storage manager 135 may also monitor and access metadata that maybe created by various storage operation cells that are in communicationwith storage manager 135. For example, metadata created and/or stored atstorage operation cells 140, 145,150, 155, 160, and 165 may be monitoredand accessed by the master storage manager 135. Master storage manager135 may forward or send the accessed metadata to one or more of thestorage devices or databases 137 to generate a centralized repository ofmetadata across the entire storage operation system 171. Thus, database137 may include information representing a unified view of the variousmetadata information collected across the different storage operationcells operating in a storage management system.

Such a unified view of the metadata collected across the entire storagenetwork may provide an advantageous benefits in the management of thenetwork. For example, the unified view may present the system, or systemadministrator with a broad view of the utilized resources of thenetwork. Presenting such data to one centralized manager may allow for amore comprehensive management and administration of network resources.The storage manager, either via a preconfigured policy or via a manualoperation from a system administrator, may reallocate resources improvenetwork efficiency. Data paths from storage operation cells may bere-routed to avoid areas of the network which may suffer from trafficcongestion by taking advantage of underutilized data paths or operationcells.

Additionally, should a storage operation cell approach, arrive at orexceed a cache size maximum, storage device capacity, or fail outright,several routes of redundancy may be triggered to ensure the data arrivesat the location for which it was intended. A unified view may providethe manager with a collective status of the entire network allowing thesystem of adapt and reallocate the many resources of the network forfaster and more efficient utilization of those resources.

In some embodiments, master storage manager 135 may store statusinformation and other information regarding its associated storageoperation cells and other system information in an index cache, databaseor other data structure. A presentation interface included in certainembodiments of the master storage manager 135 may access thisinformation and present it to users and system processes withinformation regarding the status of storage operations, storageoperation cells, system components, and other information of the system.The presentation interface may include a graphical user interface(“GUI”), a text/command-line interface, or other various userinterfaces. The presentation interface may display the overall status ofthe network to a display monitored by the system administrator. Thesystem administrator may oversee the dynamic reallocation and automaticreconfiguration of the network as events are triggered, or may take anactive role in manually reassigning roles and redistributing the loadacross the network.

In other embodiments master storage manager 135 may alert a user such asa system administrator when a particular resource is unavailable orcongested. For example, a particular storage device might be full orrequire additional media. Master storage manager 135 may use informationfrom an HSM storage operation cell and an SRM storage operation cell topresent indicia or otherwise alert a user. Additionally, master storagemanager 135 may otherwise identify aspects of storage associated withthe storage management system and hierarchy of storage operation cells.

While the embodiments described herein describe certain monitor andcontrol configurations, one skilled in the art will recognize that theseare illustrative examples and information may be presented, transmittedand monitored through a variety of methods, (i.e. personal digitalassistant (“FDA”), workstation monitor, periodic status emails, etc.)without deviating from the scope of the invention.

Alternatively, a storage manager in a particular storage operation cellmay be unavailable due to hardware failure, software problems, or otherreasons. In some embodiments, master storage manager 135 (or anotherstorage manager within the hierarchy of storage operation cells) mayutilize globally collected metadata from storage device 137 in order torestore storage operation cells. For example, master storage manager 135may alert the user that a storage device in a particular storageoperation cell is at capacity, congested, or otherwise unavailable. Themaster storage manager may then suggest, based on job and data storageinformation contained in its database, an alternate storage device. Inone embodiment, the master storage manager may dynamically respond tosuch conditions, by automatically assigning a new storage device oralternate storage path across the network based on a “best alternateavailable” basis. Alternatively, a user, or system administrator may berequired to manually reconfigure, or choose from among a group ofreconfiguration options presented by the system, to alleviate thecondition triggered the fault or alert.

The master storage manager may collect metadata at a central locationand/or maintain a representation of the metadata associated with aparticular application regardless of whether or not, the application isdistributed. A unified view across certain domains or storage operationcells in a storage system can present a global view of system resources(e.g., distribution of particular data stored on the storage devices)and may be used for various purposes such as data recovery,reconstruction, forecasting and other predictive, corrective oranalytical purpose.

The metadata may be analyzed by the master storage manager, which canuse the information for load balancing, failover and other resourceallocation tasks. The master storage manager may suggest to the systemadministrator one or more alternate data paths to a particular storagedevice, dividing data to be stored among various available storagedevices based on data type as a load balancing measure, or otherwiseoptimizing data storage or retrieval times based on the processing oftime-related metadata. In some embodiments, such options or correctiveactions may be performed automatically without an user acknowledgement.

FIG. 3 illustrates a block diagram of a hierarchically organized groupof storage operation cells in a system to perform storage operations onelectronic data in a computer network in accordance with the principlesof the present invention. As shown, the system may include a firststorage operation cell 170, a second storage operation cell 175, a thirdstorage operation cell 180. The storage operation cells 170, 175, 180may be connected by a series of communication links 235, 230, 197.Certain storage operation cells 170, 175, may include, a client 185, 186in communication with a primary volume 190, 191 for storing data, astorage manager component 195, 196 in communication with a storagemanager database 200 and a metadata storage volume 225. The secondstorage operation cell 175 may include a media agent 206 incommunication with a secondary storage volume 211. The third storageoperation cell 180 may include a metadata storage volume 220, and amaster storage manager component 215 in communication with a masterstorage manager database 220 and master metadata storage database 230.

The first storage operation cell 170, in this embodiment may beconfigured to perform a particular type storage operation, such as SRMstorage operations. For example, first storage operation cell 170 maymonitor and perform SRM-related calculations and operations associatedwith primary copy data. Thus, first storage operation cell 170 mayinclude a client component 185 in communication with a primary volume190 for storing data. Client 185 may be directed to using MicrosoftExchange® data, SQL data, Oracle data, or any other types of productiondata used in business or other applications and stored in the primaryvolume 190. Client 185 may also generate metadata based on theproduction data (e.g., from volumes 190 and 191) Storage managercomponent 195 may contain SRM modules or other logic directed tomonitoring or otherwise interacting with attributes, characteristics,metrics, and other information associated with the data stored inprimary volume 190. Storage manager 195 may track and store this andother information in storage manager database 200 which may includeindex information. For example, in some embodiments, storage managercomponent 195 may track or monitor the amount of available space andother similar characteristics of data associated with the primary volume190. In some embodiments, storage manager component 195 may also issuealerts or take other actions when the information associated withprimary volume 190 satisfies certain criteria.

Actions triggered by such an alert may include an audible or visualalert to a monitor and control station or an email or other textualnotification sent to an administrator. The alerts may contain details ofthe event or status and suggest a variety of options to correct oralleviate the network conditions for which the alert was generated.Alternatively, the system may be configured such that the storagemanager dynamically corrects or alleviates the alert conditionautomatically by reallocating network resources based on the utilizationcharacteristics of other resources in the network. In some embodiments,the network may also include other storage managers, media agents anddatabases. Storage manager 195 may also track and store the generatedmetadata associated with the stored client data in metadata storagevolume 225.

The second storage operation cell 175 may be directed to another typestorage operation, such as HSM storage operations. For example, secondstorage operation cell 175 may perform backups, migrations, snapshots,or other types of HSM-related operations known in the art. In someembodiments, data may be migrated from faster and more expensive storagesuch as magnetic storage (i.e., primary storage) to less expensivestorage such as tape storage (i.e., secondary storage).

This migration may allow the network to continue to operate at highlevels of efficiency by maintaining available resources for readilyaccessible data. Certain types of storage may be better suited tocertain types of data. Faster storage devices may be used in situationsfor which access to the data is time critical. Slower devices may beutilized to store other data for which access time is not as critical.The migration also may allow for efficient organization of differentclasses of data. A system administrator, or otherwise qualified user ofthe network, may determine that certain categories of data, or metadata,are more important than others and may need to be immediately accessibleby a system. This data may be the most recent data, the most oftenaccessed data, or data deemed “mission critical,” or any other suitabledata characteristic.

In this illustrative embodiment, second storage operation cell 175 mayinclude a client component 186 in communication with the primary volume191. In some embodiments, client component 186 and primary volume 191may be the same physical devices as the client component 185 and primaryvolume 190 in first storage operation cell 170 (e.g., logically but motphysically separated). Similarly, in some embodiments, the storagemanager component 196 and database 201 (which may include indexinformation) in second storage operation cell 175 may be the samephysical devices as the storage manager component 195 and index database200 in first storage operation cell 170. The storage manager component196, however, typically, may also contain HSM modules or other logicassociated with second storage operation cell 175 directed to performingHSM storage operations on the data of the primary volume 191. In storageoperation cell 175, storage manager 196 may also track and store thegenerated metadata associated with the data of client 186. Storagemanager 196 may store the generated metadata to the metadata storagevolume 220

Second storage operation cell 175, in this embodiment, may also includea media agent 206 and a secondary storage volume 211 configured toperform HSM-related operations on primary copy data. For example,storage manager 196 may migrate primary copy data from primary volume191 to secondary volume 211 using media agent 206. Metadata associatedwith the migrated data may be stored by media agent 205 at metadatastorage volume 220. The media agent 205 may store this metadata eitherdirectly or through the intermediary of storage manager 196. Storagemanager 196 may also track and store information associated with primarycopy migration and other similar HSM-related operations in storagemanager database 201. In some embodiments, storage manager component 196may direct HSM storage operations on primary copy data according to astorage policy associated with the primary copy 191 and stored in theindex 201. Storage manager 196 may also track where primary copyinformation is stored, for example in secondary storage 211.

The third storage operation cell 180, in this embodiment, may include amaster storage manager 215, a database 220 and a master metadata storagedevice 230. In some embodiments (not shown), additional storageoperation cells may be located hierarchically in between the thirdstorage operation cell 180 and first and second storage operation cells170, 175. In some embodiments, additional storage operation cellshierarchically superior to operation cell 180 may also be present in thehierarchy of storage operation cells.

In some embodiments, first and second storage operation cells 170, 175may be connected by communications link 197, which may be any suitablewired or wireless communications link such as a WiFi link, a fiberchannel or SCSI connection that allows storage operation cells 170, 175to communicate directly with one another (i.e., without necessarilydirectly or indirectly involving third storage cell 180). This may beaccomplished, for example, by storage manager 195 of the first storageoperation cell 175 communicating with storage manager 196 of the secondstorage operation cell via link 197. This may allow first and secondstorage operation cells 170, 175 to share information to one anothersuch as, without limitation, network status, operational metrics oravailability on primary or secondary storage.

Link 197 may allow the first and second storage operation cells also toshare information regarding any triggered events based on suchinformation. Examples of these types of events include, but are notlimited too, network congestion at any of the storage operation cells,faults in the network, limited storage capacity, slow data transfer,etc. This arrangement may allow for the direct transfer of stored datato from and from the cells (via link 197) without the need tocommunicate with or pass data through master storage manager 215. Directlink 197 may allow for the efficient communication of the storageoperation cells without having to pass through an intermediary (thethird storage operation cell in this embodiment) and causes the storageoperation cells to react or adapt to network conditions faster.

Third storage operation cell 180 may also be directed to coordinatingand managing the collection of generated metadata from all of thestorage operation cells in the hierarchy, such as the first and secondstorage operation cells 170, 175 of this embodiment. The master storagemanager 215 of the third storage operation cell 180 may communicate withthe storage managers 195, 196 of the first and second storage operationcells over the communication links 225, 230. The master storage manager215 may periodically poll the storage managers 195, 196 in order todetermine whether newly created metadata has been generated. Thispolling may occur in accordance with user defined schedules or policiesassociated with the storage operation cell. For example, a storageoperation cell may generate metadata more regularly than others, andtherefore, may be polled more regularly by master storage manager 215.

In operation, master storage manager 215 may poll storage manager 195for metadata. The storage manager 195 may then check to determinewhether updated metadata has been stored in metadata storage volume 225.If updated metadata exists, it may be sent to the master storage manager215 for storage at the master metadata storage 230. Similarly, masterstorage manager 215 may poll storage manager 196 of second storageoperation cell 175 for metadata. Storage manager 196 may also check todetermine whether updated metadata has been stored in the metadatastorage volume 220. If updated metadata exists, it may also be sent tomaster storage manager 215 for storage at master metadata storage 230.

According to another embodiment, in operation, master storage manager215 may receive metadata updates from storage managers 195, 196 of thefirst and second storage operation cells 170, 175 without the need forpolling. In this case, the storage managers within the storage operationcells notify the master storage manager of created or updated metadata.For example, under the direction of storage manager 195 of the firststorage operation cell, metadata updates may be accessed from metadatastorage 225, whereby the accessed metadata may be sent over the link 225to the third storage operation cell 180. At third storage operation cell180, master storage manager 215 may receive and store the updatedmetadata to master metadata storage 230. Similarly, under the directionof the storage manager 196 of the second storage operation cell,metadata updates may be accessed from the metadata storage device 220and sent over link 230 to third storage operation cell 180. At thirdstorage operation cell 180, master storage manager 215 may receive andstore the updated metadata to master metadata storage 230. According toother embodiments, a combination of both embodiments discussed above maybe utilized according network related or user defined information.

The hierarchy of the illustrative embodiments may provide advantages inthe maintenance and operation of a storage network. The severalcommunication links may provide redundancy of many levels (depending onthe number of storage operation cells implemented) and allow for astorage manager to direct and adapt the storage operations. In certainembodiments the storage manager may be dynamically configured toautomatically adjust the communication paths and flow of data trafficthrough the communication links and storage operation cells based on avariety of circumstances, such as traffic congestion, communication linkfailure, limited storage space, etc. In alternative embodiments, thestorage manager may present the network status, or alerts, to a systemadministrator, who in turn may manually instruct the storage manager toreallocate resources to alleviate any issues in the storage network.

FIGS. 4A and 4B present a generalized block diagram 400 illustratingmetadata flow between multiple server devices in a storage operationsystem according to an embodiment of the invention. The illustrativesystem may include a first storage operation cell 171, having anapplication server 420 and a storage manager 430. The first storageoperation cell 171 may include a communication link to a storage device440. A second storage operation cell 176 may be included also having anapplication server 425 and a storage manager 435 as well as acommunication link to a storage device 445. A third storage operationcell 181 includes an application server 405 and a storage manager 455.The third storage operation cell 181, of this embodiment, may include acommunications link to a centralized metadata storage device 450.

As illustrated in FIG. 4A, sets of metadata 410, 415 generated at theapplication server 405 of the third storage operation cell may be sentwith their corresponding application data to the application servers ofthe first and second storage operation cells 420, 425, for storage.Also, the generated metadata 410, 415 may be stored at the centralizedmetadata storage device 450 under the direction of storage manager 455of the third storage operation cell. At the first storage operationcell's application server 420, under the direction of the storagemanager 430, metadata 410 may be stored at storage device 440, while atapplication server 425 of the second storage operation cell, under thedirection of storage manager 435, metadata 415 may be stored at storagedevice 445.

As illustrated in FIG. 4B, additional metadata 460, 470 may be receivedand stored via the application servers 420, 425 of the first and secondstorage operation cells 171, 176. For example, in some embodiments,metadata 460 sent from, and/or generated by the first storage operationcell may have been received from other storage cells and stored instorage device 440 under the direction of storage manager 430.Alternatively, metadata 460 may have been generated within theapplication server 420 prior to being stored at storage device 440.Similarly, metadata 470 sent from the second storage operation cell 176may have been received from other storage cells and stored in thestorage device 445 under the direction of storage manager 435.Alternatively, metadata 470 may also have been generated withinapplication server 425 prior to being stored at storage device 470.

As mentioned above, in one embodiment, metadata 460 may have beengenerated within the application server 420 prior to being stored atstorage device 440. Therefore, various blocks or fragments of metadata(e.g., metadata 460 and 470) may be generated and/or distributed acrossdifferent storage operation cells operating over different communicationnetwork elements (e.g., server 420 and 435). According to an embodimentof the invention, metadata 460 may be migrated from storage device 440through the first storage operation cell 171 to the centralized metadatastorage device 450 via communication links 475, 480. Also, under thedirection of the storage manager 435 of the second storage operationcell and the storage manager of third storage operation cell 455,metadata 470 may be migrated from the storage device 445 to thecentralized metadata storage device 450 via communication links 477,480. As described, metadata from different operating cells and networkelements may be collected and centralized in metadata storage 450.

This embodiment of the present invention may include, among otherthings, up-to-date readily accessible metadata that may be used todetermine information corresponding to electronic data that may bestored or archived on different storage resources in a storage operationsystem. In addition to being used for storage system recovery, themetadata may be analyzed and processed in order to determine variousperformance metrics associated with the different storage operationcells of the storage operation system. As discussed in detail above,these performance metrics may include data transfer rates, trafficcongestion locations, storage space, file size, network resourceallocation, etc. One skilled in the art will recognize that thesemetrics are illustrative, and that any m suitable metric of a computernetwork may be monitored and calculated using the embodiments describedherein without departing from the scope of the invention.

FIG. 5 is a flow diagram 500 generally illustrating some of the stepsinvolved in storing metadata to a central storage device within astorage operation system according to an embodiment of the invention. Atstep 505, one or more reconstruction criteria may be used to collectmetadata from different storage locations that may be managed by one ormore storage operation cells. The reconstruction criteria may include,for example, each storage operation cell sending created metadata to adesignated storage cell that handles storing metadata to a centralstorage device or database. Each operation cell may send this metadatato the central storage device based on a pre-defined policy. Thepolicies may include, for example, the metadata reaching a thresholdsize, a user defined periodic update schedule, the type of datainvolved, based on the identity of a user creating the data, orimmediately upon creation. The metadata may be transmitted by polling orrequesting information from the operation cells based on an externaldevice or module monitoring and facilitating the migration of thecreated metadata to the central storage device, or any other criteria.

At step 510, based on the reconstruction criteria, a target storageoperation cell and storage device may be identified, selected or createdfor storing the metadata that is retrieved from different storageoperation cells and storage devices. Once the target storage device isdetermined, metadata may be identified from across the storage operationcells and sent to the target storage device (step 515). In someembodiments, metadata may include information regarding the origin orcreation point of the data to facilitate merger at the destination.

FIG. 6 is a flow diagram 600 generally illustrating some of the stepsinvolved in recreating or collecting metadata within a storage operationsystem according to an embodiment of the invention. At step 605,metadata that may be periodically replicated, backed up, archived, orotherwise copied or stored at different times and/or on differentstorage operation cell locations may be identified by a storage managermodule (e.g., metadata manager 133; FIG. 1A) within a designated storageoperation cell. The designated storage operation cell may be a anothercell or a master storage operation cell that monitors and manages SRMand HSM activities in other storage operation cells in a hierarchy ofstorage operation cells. In other embodiments, the storage operationcell may be selected based on geography (e.g., Chicago) or location(e.g., Head Office in New York) or other criteria such as capacity,availability, efficiency, user preference, convenience, etc.

Once the metadata has been identified (step 605), the target storagecell, volume or device to which the metadata is sent may be determined(step 610). This determination may be based upon any number of networkutilization metrics, including but not limited to, storage media space,traffic congestion, data transfer rates, file size, concurrent storageoperations, etc. Once identified metadata from different storageoperation cells is collected (615), it may be determined whether certainmetadata entries may be reconstructed (step 620). This may includedetermining whether sufficient metadata relating to one or more storageoperations has been identified and whether this identified metadata iscomplete, uncorrupted and/or it represents the data (e.g., whetherentries are missing and if so, is the missing information critical, suchthat not enough meaningful information can be obtained, even ifavailable records combined).

If at step 620, it is determined that the metadata cannot bereconstructed (e.g., recreated from the constituent parts retrieved fromacross the system), metadata from the one or more storage operationcells may continue to be collected (step 615) until sufficient metadatais obtained to successfully complete the reconstruction process.Alternatively, an alert may be sent indicating that the metadata cannotbe recreated based on the available information. Once reconstruction ofthe metadata occurs (step 620), the collected metadata may be merged bystoring the metadata to the target storage device (step 625).

Merging metadata may be performed as is known in the art and/or maygenerally include some or all of the following. Comparing metadata at afirst location with that at a second location as further describedherein to determine if differences exist. Determining whether there anyredundancies in metadata at the two (or more) locations. Polling orotherwise communicating with the location having metadata that is notpresent at the other location, and requesting that metadata betransmitted. Receiving and arranging the received metadata toreconstruct missing or corrupted metadata. Analyzing the reconstructedmetadata to determine whether any metadata remains missing or isotherwise unusable. Searching for additional metadata in other locationsif it is determined the reconstructed metadata section is incomplete.

FIG. 7 is a flow diagram 700 generally illustrating some of the stepsinvolved in recovering deleted metadata within a storage operationsystem according to an embodiment of the invention. At step 705, it maybe determined whether metadata has been inadvertently deleted at one ormore storage operation cells. This may be accomplished, for example, byidentifying source data, such as by an Update Sequence Number (USN),File reference number (FRN) or other identifier which has nocorresponding metadata. For example, metadata may have been deleted froma media agent module or other component associated with a storageoperation cell. Once it has been determined that metadata has beendeleted or inadvertently removed from a storage operation cell module orelement (e.g., media agent), stored metadata archives that are stored ata centralized storage location are monitored or quiesced (step 710). Thecentralized storage location may, for example, include one or morestorage devices for storing the metadata for the entire storageoperation system.

Based on monitoring the centralized storage location, at step 715 copiesof the deleted metadata files may be located and accessed from thecentralized storage location. For example, the metadata associated withthe media agent with the deleted metadata may be identified and accessedfrom the centralized storage location. At step 720, the accessedmetadata may then be sent to the location or locations from which themetadata was deleted or corrupted. The media agent with the lostmetadata may receive the metadata copies from the centralized storagelocation. This metadata is then integrated into the media agent metabaseto refresh the entries in the metabase that may have been deleted,corrupted or are otherwise missing. This may include, comparing metadatafor correspondence, and then arranging and merging metadata depending onavailability, ability to correlate metadata from different locationswith one another etc., and using any suitable integration techniques.The process may be repeated until the media agent database is fullyrefreshed or additional metadata is unavailable. This allows the presentinvention to leverage and harvest information distributed across onemore networks to reconstitute or otherwise recreate lost metadata.

Turning to FIG. 8, a flow diagram 800 is presented illustrating some ofthe steps involved in using metadata for storage system recoveryaccording to an embodiment of the invention. At step 805, metadata thatmay be created at different times and at different locations across anetwork of storage operation cells may be identified. The metadata maybe monitored by modules within the storage managers of each storageoperation cell. For example, a metadata manager 133 (FIG. 1A) mayfacilitate identification of created metadata in a storage manager.Also, modules external to the storage managers may providemetadata-monitoring capabilities. For example, metadata agent 107 (FIG.1A) within media agent 105 (FIG. 1A) may also monitor and identifycreated metadata.

At step 810, identified metadata may be sent to a central storagelocation or database and may be arranged based on temporal information,which is useful for stepping through information correlated with acertain time or event. The metadata may then be integrated or otherwiseunified with other metadata associated with the storage operationsystem. If it is determined that additional metadata may exist acrossthe various storage operation cells (step 815), the additional metadatamay continue to be identified and collected (steps 805 and 810) by thestorage manager. At step 820, the integrated metadata is copied to aremote storage device so that the metadata may be accessed and utilizedfor disaster recovery operations in order to recover stored data thatmay have been lost.

The metadata may include identification information that is associatedwith each storage device, which, in some embodiments, may be unique.Thus, using this identification information, the metadata may facilitatethe recovery of lost data by identifying the correct storage device towhich the lost data was copied. Such an implementation may allow for thefaster, more secure and more accurate recovery of lost or damaged data.In mission critical operations, it may be desired to provide a storageoperation system in which backup or stored data may be immediatelyretrieved using the most efficient and time effective components.

FIG. 9 is a flow diagram 900 illustrating some of the steps involved inusing metadata for identifying backed up storage media during datarecovery according to an embodiment of the invention. At step 905 aunique (i.e., worldwide unique) identifier may be assigned to metadataassociated with application or other information data that is copied toa storage device. The identifier may be used to identify the particularstorage device where the data is stored or backed up. Barcodes, or otheroptical patterns may be used to identify and catalog storage devices.Optical recognition systems can reliably read a barcode looking for apattern match to identify the storage media sought. If it is determinedthat the storage device includes storage media that is barcoded foridentification and selection by, for example, a robotic arm (step 910),information corresponding to the media barcode is also added to themetadata.

If no barcode data is found in the identifier, the barcode identifierinformation for the storage media may be written and stored to themetadata (step 915). At step 920, once the identifier information isadded to the metadata, it may be sent to a central storage locationcomprising one or storage devices. If data is lost from a particularstorage device (step 925), e.g., a primary storage volume, metadataassociated with the lost data may be accessed from the central storagedevice (step 930). Once accessed, information such as the media barcodeinformation and/or unique identifier may be used to determine thestorage location of the stored copy of the lost data (step 930). Thestored copy of the lost data may be then retrieved and sent to thestorage device from which the data was lost. Alternatively, if thisstorage device has malfunctioned, the retrieved or recovered data may besent to another storage device, database, or information storing device.

Using the metadata associated with the unique identifier, lost datainformation may be accessed from the correct backup storage device thatholds a stored copy of the desired data of interest. Also, using themetadata associated with the media barcode information, lost datainformation may be accessed from the correct barcode storage mediawithin a particular backup storage device in an expedited manner.

Systems and modules described herein may comprise software, firmware,hardware, or any combination(s) of software, firmware, or hardwaresuitable for the purposes described herein. Software and other modulesmay reside on servers, workstations, personal computers, computerizedtablets, PDAS, and other devices suitable for the purposes describedherein. Software and other modules may be accessible via local memory,via a network, via a browser or other application in an ASP context, orvia other means suitable for the purposes described herein. Datastructures described herein may comprise computer files, variables,programming arrays, programming structures, or any electronicinformation storage schemes or methods, or any combinations thereof,suitable for the purposes described herein. User interface elementsdescribed herein may comprise elements from graphical user interfaces,command line interfaces, and other interfaces suitable for the purposesdescribed herein. Screenshots presented and described herein can bedisplayed differently as known in the art to input, access, change,manipulate, modify, alter, and work with information.

While the invention has been described and illustrated in connectionwith preferred embodiments, many variations and modifications as will beevident to those skilled in this art may be made without departing fromthe spirit and scope of the invention, and the invention is thus not tobe limited to the precise details of methodology or construction setforth above as such variations and modification are intended to beincluded within the scope of the invention.

What is claimed is:
 1. A system for maintaining metadata in anelectronic storage network comprising: primary data stored on at least afirst storage device; at least a first and second media agents thatcreate at least secondary copies of first and second portions of theprimary data on at least a second storage device, the first media agentcreates a first set of metadata that is stored in a first metadatastorage device, and the second media agent creates a second set ofmetadata that is stored in a second metadata storage device; acentralized metadata storage device that stores at least a copy of thefirst set of metadata and a copy of the second set of metadata, whereinthe centralized metadata storage device is different than the first andsecond metadata storage devices; and at least one storage managementcomponent that: determines whether a portion of the first set ofmetadata on the first metadata storage device is missing by identifyingat least one of a sequence number and a file reference number that hasno corresponding metadata on the first metadata storage device;reconstructs a missing of the portion of the first set of metadata onthe first metadata storage device using the copy of the first set ofmetadata stored on the centralized metadata storage device.